Release 10.1A: OpenEdge Development:
Progress Dynamics Basic Development

Populating the SDO’s temp-table

Remember that you are responsible for populating the temp-table your SDO uses. The following simple example shows how you can create 10 records in your TTMyTable table when the SDO is created:

/* ********************* Main Block ***********************/ DEFINE VARIABLE iRec AS INT NO-UNDO. DO iRec = 1 TO 10: CREATE ttmytable. ASSIGN ttmytable.Field1 = iRec ttmytable.Field2 = 'Rec ' + STRING(irec). END. &IF DEFINED(UIB_IS_RUNNING) <> 0 &THEN RUN initializeObject. &ENDIF

Because you created this object directly in the AppBuilder, you must register it in the Progress Dynamics Repository.

To create or open an object in the AppBuilder and to register it in the Progress Dynamics Repository:

Save the procedure file.
From the AppBuilder main window, select File Register in Repository.
Note: In Progress Dynamics Version 1.1, it is necessary to close the object and reopen it as a file before the Register in Repository menu item will be enabled. This requirement will be corrected in a later release.

The Register in Repository dialog box appears, as shown:



Select the Product Module where the object should be registered.
Select Static SmartDataObject (SDO) as the Object Type, then choose OK.

Now you can build SmartDataViewers or SmartDataBrowsers for this SDO as you would for any other SDO. Keep in mind that the reason the SDO temp-table definition must match the name and definition of a table that can be located in a database at design time and compile time, is that visual objects, such as the SmartDataViewer, must reference that same table definition when they are compiled. There is no need for the table definition itself at run time in these visual objects, but it is needed to compile the field definitions that make up the viewer or browser.

When you drop these objects into a SmartWindow or other container, you can use them just like any other SmartObjects. The records loaded into the TTMyTable table are copied into the RowObject temp-table just as database records would be. Figure 11–1 shows a SmartWindow with a SmartDataViewer that displays the current row from the temp-table.

Figure 11–1: Test Window for Temp-Table

You can update rows in this table or add new rows to it the same as you could when using any other SDO, as shown in Figure 11–2.

Figure 11–2: Updated Test Window for Temp-Table

These rows are copied back to the TTMyTable temp-table by the SDO code. Because this is just a temp-table, any changes are lost when the object is closed, unless you write code in your application to save the changes somehow. The following code example adds a local destroyObject procedure to the SDO mytableo.w so that changes are saved (or displayed in this case) on exit:

/*---------------------------------------------------------------- Purpose: Local version of procedure destroyObject. Saves changes to the TTMyTable temp-table on exit. Parameters: <none> Notes: This example simply displays the temp-table contents to verify that changes have been saved back to the temp-table. -----------------------------------------------------------------*/ DEFINE VARIABLE cMessage AS CHAR NO-UNDO. FOR EACH TTMyTable: cMessage = cMessage + string(TTMyTable.Field1) + " " + TTMyTable.Field2 + CHR(10). END. MESSAGE cMessage VIEW-AS ALERT-BOX. RUN SUPER. END PROCEDURE.

After making a change to the first record and adding an eleventh record to the table through the SmartDataViewer, and then exiting, you can see the confirmation that your changes made it back to the TTMyTable temp-table, as shown: